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DETAILED ACTION 

Introduction 

1. Upon further review of the arguments provided by the applicant in the 
Appeal Brief filed 23 June 2008, the FINAL Office action mailed 22 January 2008 
has been withdrawn. The prosecution of this application is hereby reopened. 

2. The following is a NON-FINAL Office Action in response to the communication 
received on 23 June 2008. Claims 1-7, 9-13, and 15-18 are now pending in this 
application. 

/Kambiz Abdi/ 

Supervisory Patent Examiner, Art Unit 3692 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 1-7, 9-13, and 15-18 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Suzuki et al. (US PG Pub. No. 2002/0032616), [hereinafter Suzuki] in 
view of Schuba et al. (US PG Pub. No. 2002/0052842), [hereinafter Schuba]. 

Referring to Claim 1 : Suzuki shows a mobile server wallet provider (MSWP) 
[portal] comprising: a configuration for communicative coupling both to a plurality of 
MSWP's and also a content proxy [wallet server] (Suzuki: Figures 3-4, 6-7; Page 2, 
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Paragraph 00307/The figures depict a system that facilitates the transactions between 
multiple MSWP's where a content proxy [wallet server] would allow retrieval of various 
amounts of information regarding the MSWP//); a composite profile generator 
configured to combine a plurality of MSWP profiles into a single, composite profile for 
routing payment messages in said proxy [wallet server] to the MSWP [portal] (Suzuki: 
Page 2, Paragraph 0021, 0030// Suzuki refers to a system which combines multiple 
MSWP's and allows for financial transactions to take place//); and, selection logic 
configured to process a user selection of one of said MSWP's to process a payment 
transaction received through said proxy [wallet server] (Suzuki: Figures 3, 4, 7; Page 2, 
Paragraph 0020-0023//Upon verification of receipt, a payment transaction process 
occurs with the system//). 

Suzuki, however, does not expressly discuss a wallet 'portal'. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are number of servers within the system 
of Schuba (//Unarguably, the server which corresponds more effectively to the operation 
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of a proxy, teaches the proxy server of the instant application//). Furthermore, it is old 
and well known in the art that upon use of a mobile wallet, a composite profile is created 
for a user/subscriber in order to allow for quicker usability during each 
successive/subsequent use, thereby reducing the continuous data/bandwidth input into 
the system caused via each transaction. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 2 : Suzuki discusses a [portal//communication device//], 
wherein said content proxy [wallet server] is a wireless service proxy [wallet server] 
(Suzuki: Page 1, Paragraphs 0008-0011; Page 4, Paragraph 0049//Suzuki discloses a 
system which consists of a wireless service proxy via the Internet - Various 
communication devices are mentioned which are capable of maintaining wireless 
service proxy transmission//). 

Referring to Claim 3 : Suzuki discloses [a portal], wherein the WSP comprises [a 
filter plug-in] configured to route said payment messages [to the portal] when said 
payment messages match rules specified within said composite profile (Suzuki: Page 2, 
Paragraphs 0028-0029; Page 3, Paragraphs 0033-0038//After authentication takes 
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place within the network, payment messages are routed back and forth via the 
system//). 

Suzuki, however, does not expressly show a portal as discussed supra or a filter 
plug-in. 

The Examiner takes Official Notice to the fact that it is quite common and well 
known to one of ordinary skill in the art that a filter be involved in an initiation of an 
electronic payment transaction, a communication terminal of a customer, or a 
transaction server. A filter serves as a primary part of the communication system; the 
communication system allows a communication between the server of the merchant, 
the communication terminal and the transaction server. The filter has, among others, 
the task of forwarding certain messages concerning the electronic payment transaction 
to assigned receivers. Filters can be a part of a communication system, such as a GSM, 
GPRS, PPDC, WCDMA, UMTS, and Bluetooth type networks by way of example. In 
addition, a filter allows for, among other things, the ability for certain messages to be 
redirected to the transaction server for the communication terminal. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
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'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are a numerous amount of servers within 
the system of Schuba (//Unarguably, the server which corresponds more effectively to 
the operation of a proxy, teaches the proxy server of the instant application//). 
Furthermore, it is old and well known in the art that upon use of a mobile wallet, a 
composite profile is created for a user/subscriber in order to allow for quicker usability 
during each successive/subsequent use, thereby reducing the continuous 
data/bandwidth input into the system caused via each transaction. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 4 : Suzuki teaches a payment transaction system comprising: 
a plurality of mobile server wallet providers (MSWP's) coupled to respective on- 
line financial institutions (Suzuki: Figures 3-4, 6-7; Page 2, Paragraphs 0024, 0030; 
Page 4, Paragraphs 0052-0053//Suzuki depicts a system which combines multiple 
MSWP's, and allows for financial transactions to take place which have a relation with 
multiple financial institutions of varying types//); at least one content proxy [wallet 
server] configured for coupling both to on-line merchants and to end user customers of 
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said on-line merchants (Suzuki: Figure 1(#40); Page 3, Paragraph 0048; Page 4, 
Paragraphs 0053//The system as disclosed can be utilized by both on-line merchants 
and end-users//); and, at least one MSWP [portal] disposed between the MSWP's and 
at least one content proxy [wallet server] (Suzuki: Page 2, Paragraphs 0021, 0030; 
Page 3, Paragraph 0031). 

Suzuki, however, does not expressly discuss a wallet 'portal'. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are a numerous amount of servers within 
the system of Schuba (//Unarguably, the server which corresponds more effectively to 
the operation of a proxy, teaches the proxy server of the instant application//). 
Furthermore, it is old and well known in the art that upon use of a mobile wallet, a 
composite profile is created for a user/subscriber in order to allow for quicker usability 
during each successive/subsequent use, thereby reducing the continuous 
data/bandwidth input into the system caused via each transaction. 
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At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 5 : Claim 5 parallels the limitations of Claim 2. As such, Claim 
5 is rejected under the same basis, as is Claim 2 as mentioned supra. 

Referring to Claim 6 : Suzuki discusses a system, wherein said content proxy 
[wallet server] further comprises [a filter plug-in] configured to route payment messages 
to said MSWP [portal] when said payment messages match rules specified within a 
profile provided to said [filter plug-in] by said MSWP [portal] (Suzuki: Page 2, 
Paragraphs 0028-0029; Page 3, Paragraphs 0033-0038//After authentication takes 
place within the network, payment receipt messages are routed back and forth 
throughout the system//). 

Suzuki, however, does not expressly show a portal as discussed supra or a filter 
plug-in. 

The Examiner takes Official Notice to the fact that it is quite common and well 
known to one of ordinary skill in the art that a filter be involved in an initiation of an 
electronic payment transaction, a communication terminal of a customer, or a 
transaction server. A filter serves as a primary part of the communication system; the 
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communication system allows a communication between the server of the merchant, 
the communication terminal and the transaction server. The filter has, among others, 
the task of forwarding certain messages concerning the electronic payment transaction 
to assigned receivers. Filters can be a part of a communication system, such as a GSM, 
GPRS, PPDC, WCDMA, UMTS, and Bluetooth type networks by way of example. In 
addition, a filter allows for, among other things, the ability for certain messages to be 
redirected to the transaction server for the communication terminal. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are number of servers within the system 
of Schuba (//Unarguably, the server which corresponds more effectively to the operation 
of a proxy, teaches the proxy server of the instant application//). Furthermore, it is old 
and well known in the art that upon use of a mobile wallet, a composite profile is created 
for a user/subscriber in order to allow for quicker usability during each 
successive/subsequent use, thereby reducing the continuous data/bandwidth input into 
the system caused via each transaction. 
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At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 7 : Suzuki discloses a method for processing a payment 
transaction in a mobile commerce system (Suzuki: Page 2, Paragraph 0016; Page 3, 
Paragraphs 0031-0032//Suzuki discloses a e-commerce payment transaction system 
and method//), the method comprising the steps of: processing a payment message in a 
[portal] to identify one of a selection of mobile server wallet providers to handle an 
associated payment transaction (Suzuki: Page 2, Paragraph 0016; Page 3, Paragraphs 
0031-0032//A payment transaction is dedicated to a given mobile server wallet//); 
routing said payment message to said payment message to an identified one of said 
MSWP's (Suzuki: Page 2, Paragraphs 0016, 0023; Page 4, Paragraphs 0052-0053//A 
unique identifier is traced with the payment transactional information//); combining 
individual MSWP profiles for each of said MSWP's into a composite profile (Suzuki: 
Figures 3-4, 6-7; Page 2, Paragraph 0030//Suzuki teaches a system and method which 
facilitates transactions between multiple MSWP's where a content proxy [wallet server] 
allows retrieval of financial information regarding the MSWP, thereby causing storage to 
a composite profile//); and, providing said composite profile to a content proxy [wallet 



Application/Control Number: 10/758,853 Page 1 1 

Art Unit: 3692 

server] for use in trapping payment messages passing through said content proxy 
[wallet server] between an on-line merchant and a customer in the mobile commerce 
system (Suzuki: Page 1, Paragraphs 0008-0011; Page 4, Paragraph 0049). 

Referring to Claim 9 : Suzuki shows a method of processing comprising the steps 
of: identifying a customer associated with said payment message (Suzuki: Page 2, 
Paragraphs 0016, 0021, 0028//Suzuki teaches a system where a user [customer] is 
identified//); parsing a profile associated with said customer to determine a selection of 
preferred MSWP's (Suzuki: Figure 3-Also See Page 4, Paragraphs 0059-0060//Suzuki 
displays a system which allows a selection of various MSWP's//); rendering a user 
interface presenting said selection of preferred MSWP's to said customer (Suzuki: 
Figure 3-Also See Page 4, Paragraphs 0059-0060); and, selecting a particular one of 
said preferred MSWP's to handle said associated payment transaction based upon data 
provided by said customer in said user interface (Suzuki: Page 5, Paragraphs 0061- 
0064//A financial payment transaction occurs at this juncture in the system, upon final 
selection of a MSWP//). 

Referring to Claim 10 : Suzuki discusses a method comprising the step of relaying 
payment transaction data produced by said selected one of said preferred MSWP's to a 
customer (Suzuki: Page 3, Paragraph 0021; Page 8, Paragraphs 105, 106, 
1 10//Communication between a MSWP and a customer are described//). 

Referring to Claim 1 1 : Suzuki discloses a method comprising the step of relaying 
payment transaction data produced by said selected one of said preferred MSWP's to a 
merchant associated with said payment transaction (Suzuki: Page 3, Paragraph 0021; 
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Page 8, Paragraphs 105, 106, 1 10//Communication between a MSWP and a merchant 
are described//). 

Referring to Claim 12 : Suzuki teaches a method wherein said relaying step 
comprises the step of relaying a payment guarantee to said merchant by said selected 
one of said preferred MSWP's (Suzuki: Page 2, Paragraphs 001 6-001 7//While no 
'formal' guarantee is expressly mentioned by Suzuki, the transaction will not terminate 
until payment has been received, hence, a payment guarantee is in effect//). 

Referring to Claims 13-18 : Claims 13-18 are directed towards a machine 
readable storage for Claims 7-12. As such Claims 13-18 are rejected under the same 
basis as are Claims 7-12 as mentioned supra. 

Examiner Note 

5. The Examiner has pointed out particular reference(s) contained in the prior 

art of record within the body of this action for convenience of the Applicant. Although 
the specified citations are representative of the teachings in the art and are applied to 
the specific limitations within the individual claim, other passages and figures may 
apply. Applicant, in preparing the response, should fully consider the entire 
reference as potentially teaching all or part of the claimed invention, as well as the 
context of the passage as taught by the prior art or disclosed by the Examiner. 

Conclusion 

6. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 
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Schutzer (US Pat. No. 6,873,974) teaches a system and method for use of 
distributed electronic wallets. 

Any inquiry concerning this communication should be directed to BENJAMIN S. 
FIELDS at telephone number 571.272.9734. The examiner can normally be reached 
MONDAY THRU FRI between the hours of 9AM and 7PM. If attempts to reach the 
examiner by telephone are unsuccessful, the examiner's supervisor, KAMBIZ ABDI can 
be reached at 571.272.6702. The fax phone number for the organization where this 
application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
Benjamin S. Fields 
1 July 2008 



/Kambiz Abdi/ 

Supervisory Patent Examiner, Art Unit 3692 



